@pshipton is there a compile time flag that lets us distinguish between IBM Java8 and Semeru8?

#if defined(OPENJ9_BUILD)

What you could do is not distinguish in the VM, but add the option to enable for IBM Java 8 in options.default. That's what we've done for a few other things.

-Djava.lang.stringBuffer.growAggressively=false
-XX:+OriginalJDK8HeapSizeCompatibilityMode
-XX:+LegacyXlogOption

What is the point of this? We only go into extended mode for FSD (i.e. when certain JVMTI capabilities are requested), so this would have no impact on an actual application that is not running in debug mode.

What is the point of this?

I want to disable extended HCR by default so we can have guarantees about ramClass addresses.

We only go into extended mode for FSD (i.e. when certain JVMTI capabilities are requested), so this would have no impact on an actual application that is not running in debug mode.

If someone is running in debug mode and it fails because we have explicitly disabled extended HCR, I'd like them to get a warning message indicating that this is the case.

This seems like a waste of code. Just return false from areExtensionsEnabled if the flag is set. Printing to the console is a waste of time (and you would need to NLS the messages). JVMTI has error codes that detail why the HCR failed - that should be sufficient for a feature that no one uses.

If we're not removing the extensions entirely, then we will still need to maintain the related code paths, so I'm still not convinced this is useful.

This seems like a waste of code. Just return false from areExtensionsEnabled if the flag is set. Printing to the console is a waste of time (and you would need to NLS the messages). JVMTI has error codes that detail why the HCR failed - that should be sufficient for a feature that no one uses.

The issue I am trying to address is the case where someone is currently relying on extensions, and then gets a jvmti error. If they haven't changed their application or setup then any failure would be surprising. So the error message helps a user quickly mitigate the issue.

If we're not removing the extensions entirely, then we will still need to maintain the related code paths, so I'm still not convinced this is useful.

Long term I'd like to remove it. This is a first step in doing so. As part of this change I'd like to announce deprecation for future removal.

We have no idea if anyone is using the feature. So I think having some kind of warning message is the safest route forward.

jenkins test sanity zlinux jdk17

I suspect there will need to be changes to some tests. I'll run a sanity build now to see what fails.

jenkins test sanity zlinux jdk8

Looks like we only have one test for extended HCR which will need the command line option added:

TestRefreshGCSpecialClassesCache_BCI_EXTENDED_HCR_SE80_0

jenkins test sanity,extended zlinux jdk8

jenkins test extended zlinux jdk8

jenkins test sanity,extended zlinux jdk8

jenkins test extended zlinux jdk8

jenkins test extended zlinux jdk8

Is the options.default file processed for OpenJ9? If so, you may need to ifdef the default bit set.

options.default is used by OpenJ9. The idea is to have the code set the default for OpenJ9 builds, and then modify the options.default for IBM Java 8 (in closedj9) to override the default by using the option.

jenkins test sanity,extended zlinux jdk21

jenkins compile win jdk8

I won't merge this until the closedj9 change is made.

I won't merge this until the closedj9 change is made.

closedj9 changes are merged

Pls don't forget to open the docs issue.